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Abstract 

Among anonymous communication protocols, DC-nets 
have long held attraction for their strong security against 
traffic analysis. Recent work has made DC-nets more 
scalable and practical, but existing systems remain sen- 
sitive to DoS attacks: disruptors can anonymously "jam" 
communications, completely or selectively, until the 
group re-forms or completes a time-consuming and com- 
plex "blame" procedure. To address this constraint, 
we present Verdict, the first practical anonymity sys- 
tem implementing a proactively verifiable DC-nets pro- 
tocol: participants encrypt messages in algebraic group 
elements, combine ciphertexts via group arithmetic, and 
use knowledge proofs to exclude misbehavior before it 
can disrupt communication. We develop and compare 
three different verifiable DC-nets schemes: a previously 
proposed, yet not implemented pairing-based approach, 
and two new, more efficient schemes operating in normal 
modular integer and elliptic curve groups. Evaluation of 
Verdict using microbenchmarks and trace-driven traffic 
loads reveals that verifiable DC-nets may be surprisingly 
usable for applications such as anonymous microblog- 
ging in groups with hundreds of members. 

1 Introduction 

A right to anonymity is fundamental to democratic cul- 
ture and freedom of speech [3, 34 1, protecting minor- 
ity groups from discrimination |33|, and gaining impor- 
tance as online forums have become venues for peace- 
ful resistance to repression OTI . Relay tools such as 
Tor ifTTIl offer practical and scalable anonymous com- 
munication, but are vulnerable to many traffic analysis 
attacks [ 4 25 29 ] , which are likely to be feasible for pow- 
erful adversaries such as an authoritarian regime's state- 
controlled ISR 

Dining cryptographers networks or DC-nets ap- 
proach IfTTIl offers strong security even against traffic 
analysis. Recent experimental systems such as Herbi- 
vore 121 11321 and Dissent [ 12 38] have brought DC-nets 
closer to practicality by improving their usability, ac- 
countability, and scalability. Even with the accountable 
protocols used in Dissent, however, these systems are 
vulnerable to denials-of-service (DoS) attacks: a disrup- 



tive member can "jam" communications within a group, 
completely or selectively, until the group runs a time- 
consuming and complex retroactive blame procedure to 
trace and exclude the disruptor. In Dissent, for example, 
tracing a disruptor in a 1,000-member group takes over 
60 minutes [38 1, immediately followed by a restart in the 
protocol "from scratch" after having made no communi- 
cation progress during the disruption. An adversary pow- 
erful enough to infiltrate such a group with / colluding 
members could "sacrifice" them one at a time to disrupt 
all communication for / contiguous hours at any time — 
likely enough time to cause a communications blackout 
prior to or during an important mass protest, for example. 

To thwart such disruptions, Golle and Juels [22] pro- 
posed a DC-nets scheme that makes ciphertexts ver- 
ifiable, using pairing-based cryptography and proofs 
of knowledge, thus proactively protecting groups from 
anonymous disruption. An adversary cannot mount DoS 
attacks of the type outlined above against the Golle- Juels 
protocol because he cannot inject incorrect DC-nets ci- 
phertexts in the first place. To our knowledge no verifi- 
able DC-nets scheme such as this has been implemented 
or experimentally evaluated, however, perhaps in part be- 
cause the computational overhead imposed by pairing- 
based cryptography was perceived to be prohibitive. This 
paper explores for the first time the use of verifiable 
DC-nets in practical anonymity systems, implementing 
both the Golle-Juels scheme and two novel, more com- 
putationally efficient variants that avoid the need for 
pairing-based cryptography. Experimentation with these 
schemes leads us to the conclusion that verifiable DC- 
nets can offer not only resistance to DoS attacks, but 
surprisingly, may be more computationally efficient than 
traditional XOR-based DC-nets when scaled to the large 
anonymity sets users are likely to desire in practice. 

The Golle-Juels scheme uses group arithmetic to con- 
struct proofs of knowledge, namely, that a ciphertext is 
either cover traffic or the slot owner's encrypted mes- 
sage. In that context, Golle and Juels makes use of a 
pairing-based scheme primarily for the purpose of con- 
structing many shared secrets, a fundamental unit in DC- 
nets. However, one disadvantage of this scheme is that 
each ciphertext element requires a computationally ex- 
pensive pairing operation. To address this issue, we in- 
troduce two novel schemes, derived from ElGamal en- 
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cryption and hashing, to generate shared secrets in a sin- 
gle group avoiding expensive pairing operations. 

In Verdict (VERifiable Dining CrypTographers), we 
have implemented all three schemes for comparison, to 
our knowledge the first practical implementation and 
evaluation of any verifiable DC-nets scheme. Our im- 
plementation of Golle-Juels' Pairing scheme uses the 
Stanford-based PBC (Pairing-Based Cryptography) li- 
brary, while our two new schemes support both ellip- 
tic curve and integer groups as implemented by several 
cryptographic libraries: OpenSSL, Crypto++, andBotan. 
We use microbenchmarks to compare the schemes, find- 
ing significant improvements over the pairing approach 
when using regular elliptic curves and integers, and 
finding the Hashing scheme using OpenSSL-based el- 
liptic curves to be most efficient. In a more realistic 
trace-based Twitter evaluation on DeterLab, our Hashing 
scheme handles significantly more participants than the 
pairing approach, and compares well with Dissent, with 
several hundred members participating. 

While verifiability adds significant computational 
cost, we feel this cost may be justified in situations 
in which DoS attacks by powerful adversaries may be 
likely, and our experimental results suggest that verifi- 
able DC-nets may be practical and scalable at least for 
some communication applications. 

This paper's primary contributions are: 

• The first practical implementation and experimental 
evaluation of verifiable DC-nets protocols. 

• Two novel verifiable DC-nets schemes that work with 
conventional modular integer or elliptic curve groups, 
and require no expensive pairing-based cryptography. 

• An experimental demonstration that verifiable DC-nets 
may be sufficiently practical and scalable for some ap- 
plications such as anonymous microblogging. 

Section [2] of this paper covers background informa- 
tion on DC-nets. We present our DC-net protocol in Sec- 
tion[3]and our verifiable ciphertext construction schemes 
in Section [4] We discuss practical issues in Section [5] 
Section [6] presents our evaluation of Verdict. We com- 
plete the paper with a brief discussion and conclusion in 
Sections [7] and[H] respectively. 

2 Background and Motivation 

This section first summarizes the basic DC-nets concept 
and known generalizations, then outlines existing ap- 
proaches to the disruption problem and the benefits of 
proactive verifiability. 

2.1 DC-nets Overview 

DC-nets [11] provide anonymous broadcast communica- 
tion within a group of participants. Each member con- 
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Figure 1 : The basic DC-nets algorithm 

tributes an equal length ciphertext that, when combined 
with other members' ciphertexts, produces a set of mes- 
sages. In a given exchange, all group members know that 
each message was sent by a group member — but they do 
not know which member sent a given message. 

In its simplest form, illustrated in Figure Q] we as- 
sume one group member wishes to broadcast a 1-bit mes- 
sage anonymously. To do so, every pair of group mem- 
bers flips a coin, secretly agreeing on the random out- 
come of that coin flip. An A^-member group thus flips 
N(N — 1 ) coins in total, of which each member observes 
the outcome of N — 1 coins. Each member then XORs 
together the values of the N — 1 coins he observes, and 
additionally the member who wishes to broadcast the 1- 
bit message XORs in the value of that message, to pro- 
duce that member's DC-nets ciphertext. Each member 
then broadcasts her 1-bit ciphertext to the other mem- 
bers. Finally, each member collects and XORs all N 
members' ciphertexts together. Since the value of each 
shared coin is XORed into exactly two members' cipher- 
texts, all the coins cancel out, leaving only the anony- 
mous message, while provably revealing no information 
about which member sent the message. 

As a standard generalization of DC-nets to communi- 
cate L-bit messages, all members in principle simply run 
L instances of the protocol in parallel. Each pair of mem- 
bers flips and agrees upon L shared coins and each mem- 
ber XORs together the L-bit strings he observes with the 
optional L-bit anonymous message to produce L-bit ci- 
phertexts, which XOR together to reveal the L-bit mes- 
sage. For efficiency, in practice each pair of group mem- 
bers forms a cryptographic shared secret — via Diffie- 
Hellman key agreement, for example — then group mem- 
bers use a cryptographic pseudo-random number gener- 
ator (PRNG) to produce the L-bit strings. 

As a complementary generalization, we can use any 
finite alphabet or group in place of coins or bits, as long 
as we have: (a) a suitable combining operator analogous 
to XOR; (b) a way to encode messages in the chosen al- 
phabet; and (c) a way to generate complementary pairs 
of one-time pads in the alphabet that cancel under the 
chosen combining operator. For example, the alphabet 
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might be 8-bit bytes, the combining operator might be 
addition modulo 256, and from each pairwise shared se- 
cret, one member of the pair generates bytes Si,... 
from a PRNG, while the other member generates corre- 
sponding two's complement bytes —Si, . . . , — B^. 

Verifiable DC-nets [22 1 build primarily on this latter 
generalization, by using algebraic groups, such as large 
prime-order integer groups or elliptic curve groups, as 
the DC-nets alphabet. While using such groups is un- 
necessary to provide anonymity, their properties offer 
disruption resistance, by enabling members to prove the 
correct construction of their ciphertexts without compro- 
mising the secrecy of the shared pseudorandom seeds. 

2.2 Motivation and Related Work 

Chaum recognized the problem of disruption attacks in 
his original formulation of DC-nets |[TTI . and proposed 
a retroactive, probabilistic approach to tracing disrup- 
tors via traps, which was expanded upon by Waidner and 
Pfitzmann |[331l3"6l . 

Herbivore 121U321 sidestepped the disruption issue via 
a dynamic group formation protocol, enabling nodes to 
leave disrupted groups and form new groups randomly 
until they find a group with no disruptors. Unfortu- 
nately, the likelihood that a group contains some mali- 
cious node is likely to increase rapidly with group size, 
and hence anonymity set, limiting this approach, and 
related partitioning approaches [1], to systems offering 
small anonymity sets. Further, in an analog to a known 
attack against Tor J7], an adversary might selectively dis- 
rupt only groups he has not completely compromised, 
e.g., by isolating a victim in a group whose other nodes 
are all compromised. Thus, in an environment with a 
powerful adversary controlling many nodes, after some 
threshold a victim becomes more likely to "settle into" a 
group that works because it is completely compromised, 
than into a group that is uncompromised. 

Dissent [12 38] explored the use of verifiable shuf- 
fles J9, 26] to establish an agreed-upon transmission 
schedule for DC-nets, enabling groups to guarantee a "1- 
to-1" correspondence of well-known group members to 
anonymous transmission slots for example. In the orig- 
inal Dissent protocol fl2l . anonymous senders use the 
verifiable shuffle to distribute transmission assignments 
with associated hashes to all group members, making it 
simple to identify disruptors who transmit incorrect ci- 
phertexts, at the cost of requiring an expensive, serial- 
ized shuffle before each DC-nets transmission. A more 
recent version l38l introduces a retroactive "blame" pro- 
tocol that runs after a disruption has been detected, re- 
quiring an expensive shuffle, thus creating the significant 
DoS attack vulnerability discussed earlier. 



2.3 Practical Anonymity for Open Groups 

In many online venues, such as blogs, chat groups, and 
social networks, the entire set of users do not know 
each other. While close-knit groups may contain few 
disruptors, larger or more administratively open groups 
are likely to be easy for disruptors to infiltrate. While 
retroactively accountable protocols can eventually iden- 
tify and expel disruptors, they may be vulnerable to dis- 
ruption for long enough periods to ruin the service for 
honest participants. Verdict's verifiability property po- 
tentially enables DC-nets to apply to a wider range of 
applications in which users may not be familiar with 
each other. We envision that a DC-net constructed using 
our primitives could be ideal for an anonymous Twitter 
or chatroom during controversial events in which some 
users may wish to disrupt the flow of communication and 
thoughts. Our evaluations later in Section |6*31 thus focus 
in part on such chat/microblogging scenarios. 

3 Verdict Architecture 

In this section we describe the individual components of 
Verdict and how they combine to form the overall anony- 
mous communication system. 

3.1 Deployment Model and Assumptions 

Verdict builds on Dissent 0711381 . using the same multi- 
provider cloud model illustrated in Figure [2] (a) to 
achieve scalability and resilience to ordinary node and 
link failures. In this model, a communication group 
consists of mostly unreliable clients, and a few servers 
assumed to be highly available and well-provisioned. 
Servers in a group should be administered independently, 
each furnished by a different anonymity provider for 
example, although the servers may be geographically 
and/or topologically close (perhaps even located in sepa- 
rate, locked cages in the same data center). 

Clients directly communicate with a single upstream 
server, while each server communicates with all other 
servers. This topology, shown in Figure [2] (b), re- 
duces the communication and computation burden on the 
clients, and enables the system to make progress regard- 
less of client churn. In particular, clients need not know 
which other clients are online at the time they submit 
their DC-net ciphertexts to their upstream server; clients 
assume only that all servers are online. 

To ensure anonymity and security, clients need not as- 
sume that any particular server is trustworthy — a client 
need not even trust its immediately upstream server. In- 
stead, clients trust only that there exists any one server 
who is honest, an assumption we previously dubbed 
anytrust |37, 38]. as a trust analog to anycast commu- 
nication. Verdict, like Dissent, achieves security un- 
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Figure 2: Dissent deployment model, physical communication topology, and DC-nets secret sharing 



der the anytrust assumption through the DC-nets key- 
sharing model shown in Figure|2](c). Each client shares 
a secret with every server, rendering client ciphertexts in- 
decipherable without the cooperation of all servers, and 
hence protecting a client's anonymity even if its imme- 
diately upstream server is malicious. A malicious server 
might refuse to service honest clients, but such refusal 
does not compromise clients' anonymity, and victims 
can simply switch to a different server. Each client ulti- 
mately obtains an anonymity set consisting of all honest 
clients, provided the anytrust assumption holds and mes- 
sage contents do not reveal sender identity information. 

Our current design assumes that servers are highly 
available: if one server goes offline, the system cannot 
make progress, since the offline server might be the one 
honest server. A malicious server could use this property 
to block the protocol's progress by refusing to respond 
to messages during execution of the protocol. In a real- 
world deployment, we expect servers to be run by well- 
known and accountable organizations, so the servers' 
owners could deal with such failures through administra- 
tive channels. The remaining servers could form a new 
group with the unresponsive server excluded, for exam- 
ple. Clients, likewise, would either have to trust that one 
of the remaining servers is honest or stop participating 
in the protocol. Byzantine consensus techniques might 
be used to mask server failures, at the cost of requiring 
stronger security assumptions [38, Section 3.11]. 

3.2 Verdict Protocol Overview 

As in Dissent, Verdict uses a verifiable shuffle |9l|26] to 
set up a fixed DC-net transmission schedule. To start 
a session, each node submits an encrypted pseudonym 
signing key to a verifiable shuffle. The servers shuffle the 
public pseudonym keys and output them in random or- 
der. The security of the shuffle implies that, as long as at 
least one server is honest, no one (even a colluding set of 
servers) knows which client submitted which pseudonym 
key. The order in which the keys appear in the shuffle's 
output determines the order in which nodes will anony- 
mously transmit in subsequent communication rounds. 

Verdict clients use these keys to prove the correctness 
of the ciphertexts they submit. When a client submits a 
ciphertext for a slot that she does not own, the client must 
submit an empty ciphertext — an encryption of the group 



Algorithm 1 Verdict Client Protocol 



[Set-up] Slot Assignment Each client i transmits an 
anonymous key in a verifiable shuffle. The shuffle pro- 
duces a random permutation with client i's pseudonym 
public key located at 7C(i), the client's DC-net slot. 
For each message transmission round: 

1. Client Ciphertext Generation Client i generates a 
client ciphertext for each transmission slot t, Q t t, 
and multiplies his message m; into his slot, Q = 
TOjC, n (f, . Client i then produces a proof of correctness 
for each ciphertext and submits the set of ciphertext- 
proof tuples to its upstream server. 

2. Client Verification Every client verifies the M server 
signatures on the vector of plaintexts m. Clients ac- 
cept the plaintext as valid if every server's signature 
is valid. Otherwise, the client concludes that its up- 
stream server is dishonest. 

identity element, i.e., 1 — so that his ciphertext does not 
corrupt the slot owner's anonymous transmission. When 
a client submits a ciphertext for a slot that she does own, 
the client's ciphertext encodes her anonymous plaintext 
message. To prove the validity of a ciphertext, the client 
proves that either the ciphertext is an encryption of 1 or 
the client knows the secret pseudonym key for the slot 
in question. Ciphertexts and their associated proofs are 
constructed using the protocols defined in Section|4] 

We summarize Verdict's client and server protocols 
in Algorithm Q] and [2] respectively. To prevent replay 
attacks, messages sent by participants contain a round 
nonce and are signed by the participants' long-term sign- 
ing key, and duplicate ciphertexts are ignored. 



4 Verifiable Ciphertext Constructions 

This section describes three verifiable DC-net cipher- 
text constructions, starting with the simplest variant 
and building to the most complex and efficient scheme. 
Throughout, unless otherwise noted, group elements are 
members of a finite cyclic group G in which the Deci- 
sion Diffie-Hellman (DDH) problem [5] is believed to be 
hard, and g is a well-known generator of G. 



4 



Algorithm 2 Verdict Server Protocol 
[Set-up] Slot Assignment Each server obtains the set of 
client pseudonym public keys from a verifiable shuffle. 
For each message transmission round: 

1 . Ciphertext Set Sharing Once server j receives a ci- 
phertext from each of its downstream clients, j broad- 
cast the set of ciphertexts, C/, to all servers. 

2. Server Ciphertext Generation Once server j re- 
ceives all servers' client ciphertext sets, j assembles 
the complete client ciphertext set, C\ || . . . \ \Cm- Server 
j checks the validity of each client ciphertext proof, 
and removes any invalid client ciphertexts from the 
set. Server j then generates a complementary server 
ciphertext Sj, computes a proof of correctness for Sj, 
and broadcasts this ciphertext and proof to all servers. 

3. Plaintext Reveal Upon receiving and validating the 
server ciphertext from each server, server j computes 
the set of anonymous plaintext messages as: 

i j 

The server signs the set of plaintext messages and 
broadcasts the signature (7 ; - to all servers. 

4. Plaintext Sharing Upon receiving and validating the 
signatures from all other servers, each server sends 
the set of messages m, along with the M signatures 
(7i , . . . , <Tm, to each of its downstream clients. 

Invalid client messages, with incorrect signatures or 
proofs, are dropped and ignored. Invalid server actions 
halt the protocol and require external resolution. 

4.1 ElGamal- Style Construction 

Background The first approach takes inspiration from 
the ElGamal public-key encryption scheme JT9). In El- 
Gamal encryption, public/private keypairs have the form 
(B,b) = (g b ,b), and plaintexts and ciphertexts are ele- 
ments of the group G. To encrypt a message, a sender 
first creates an ephemeral keypair (R,r) = (g r ,r), and 
then computes the Diffie-Hellman shared secret using the 
recipient's public key, B 1 = g br . To encrypt a message m, 
the sender multiplies the plaintext with the shared secret 
and appends the ephemeral public key: 

(R,mB r ) = (g r ,mg br ) 

To decrypt the message, the recipient uses the 
ephemeral public key R to compute the inverse of the 
Diffie-Hellman shared secret, R~ b = g~ rb . By multiply- 
ing this inverted secret with the ciphertext, the recipient 
strips off the encryption revealing the secret message: 

= (R- b ){mB r ) 
m={g- rb ){mg rb ) 



Construction In Verdict's ElGamal ciphertext con- 
struction, instead of encrypting a message for a single re- 
cipient, the anonymous sender encrypts the message with 
the public keys of all servers. Given the servers' public 
keys (B\,...,B M ) = (g bl , . . . ,g bM ), a Verdict client ci- 
phertext takes the form: 

R,m(BiB 2 ...B M y 

If the client is not the slot owner, the client sets m = 1. 

Without the decryption keys (b\ . . .but), based on the 
DDH assumption it is infeasible to determine whether 
m is 1 or some other value. Thus, an adversary cannot 
distinguish an encrypted plaintext from cover traffic. 

Upon collecting a set of clients ciphertexts C\,... ,Cn 
each server j computes a server ciphertext using the 
product of the clients' ephemeral public keys: 

S J = (R l ...R N )- b J 

The product of all client and server ciphertexts then re- 
veals the plaintext message: 

m = (C l ...C N )(S l ...S M ) 

As in standard ElGamal encryption, Verdict's ElGa- 
mal ciphertext construction requires a unique ephemeral 
public key R for each plaintext element, otherwise an at- 
tacker could compute the ratio of the plaintext messages 
from two ciphertexts: 

C = m(BxB 2 ...B M ) r Cf =m'(B 1 B 2 ...B u y 
C/C' = m/m 

Thus, a ciphertext that encrypts a plaintext of L group 
elements contains L ciphertext elements, L ephemeral 
keys, and 0(L) proof-of-knowledge elements. 

Proof of Validity To prove an ElGamal ciphertext 
valid, the sender must demonstrate that either it has gen- 
erated a correct cover ciphertext (m= 1) or it knows the 
slot owner's secret pseudonym key y. Using standard 
discrete logarithm proof-of-knowledge techniques iflOl . 
and inspired by the Golle-Juels verifiable DC-net con- 
struction [22 1, the sender constructs a proof that: 

PoK{r[l],...,r[L],y: 

C{l} = (B 1 ...B M yWAR[l]=g<W \ 
A---A 

C[L] = (B l ...B M y [L] AR[L\=g r ^ J 
VY = g y} 

Each server /', with public key Bj, produces a proof that 
its ciphertext corresponds to the set of ephemeral client 
public keys Ri , . . . 

/ S[l] = (R 1 [l]...R N [l})- b AB j = g b \ 
PoK{b: A — A } 

V S[L] = (R l [L]...R N [L})- b AB J =g b J 
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4.2 Golle-Juels Pairing Construction 

Background A major drawback of the ElGamal con- 
struction is that for each group element containing en- 
crypted message data, an ephemeral public key and an 
additional zero-knowledge proof element must be trans- 
mitted with it. A message of L group elments thus ex- 
pands to 3L + 0(1) elements under ElGamal encryption. 

The Golle-Juels approach solves this problem with bi- 
linear maps, instantiated using pairings [22]. A symmet- 
ric bilinear map maps two elements of a group G\ into a 
target group G 2 '- 

e:G 1 xGi^G 2 
A bilinear map has the property thatfl 

e(aP,bQ)=e(P,Q) ab 

To be useful, the map must also be non-degenerate (if 
P 7^ 0, e(P,P) is not the identity element) and efficiently 
computable |6|Q 

Using a pairing function, two individuals using long- 
lived public keys, A = g" and B = g b , can generate a se- 
quence of secrets: 

e(A,H(l))V(A,H(2))V.. 
= i(B,H(l)) a ,e(B,H(2)) a ,... 

using some public hash function H : {0, 1}* — > G\. 

Since pairing allows a single pair of public keys to 
generate a sequence of shared secrets, clients need not 
generate ephemeral public keys for each ciphertext ele- 
ment they send. Instead, clients use only their long-term 
public keys to generate ciphertext elements, resulting in 
shorter ciphertexts and shorter correctness proofs. 

Construction We modify the Golle-Juels construction 
to suit our purposes in two ways: (1) we adapt the 
construction for a client/server key-sharing graph (Sec- 
tion |3.1| ), where clients encrypt only with the public keys 
of servers and vice-versa, and (2) we use verifiable shuf- 
fles for slot scheduling (Section [3T2l instead of Golle and 
Juels' probabilistic technique. 

For a set of server public keys B\,... ,Bm and a client 
public key A = g", a pairing-based ciphertext takes the 
form (for I = l,...,L): 

m[l}e(B l B 2 ...B Ml T[l}) a 

1 Since G\ is usually an elliptic curve group, the generator of Gi 
is written as P (an elliptic curve point) and the repeated group opera- 
tion is written as aP instead of g" . We will use the latter notation for 
consistency with the rest of this section. 

2 The existence of this pairing operation means that the Decision 
Diffie-Hellman problem is not hard in Gi . To determine if a tuple 
(g",g b ,g c ) is a Diffie-Hellman tuple (g a , g b , g ab ) , a distinguisher can 

teste(g a ,g b ) = e{g c ,g). 



where T is a round nonce computed using a public hash 
function in every protocol round. As before, m = 1 if the 
client is not the slot owner. 

The ciphertext of a server with public key B = g b in 
response to a set of clients with public keys A\ . . . . ,An is 
then (for I = 1, . . . ,L): 

e(A l A 2 ...A N ,T[l])- b 

As in the ElGamal construction, to reveal the plain- 
text message for a slot, the servers take the product of all 
client and server ciphertexts. 

Proof of Validity The pairing construction has a sim- 
pler proof of ciphertext correctness than the ElGamal 
scheme, since the exponents on all of a client's cipher- 
text elements C[l], . . . ,C[L] are the same: 

/ C[\]=e(B l ...B M ,T[\\y \ 
PoK{a,;y: A — A VF = g y } 

V C[L] =e(B l ...B M ,T[L]) a J 

Similarly, the server proof has the form: 

/ C[X]=e{A x ...A N ,T[\))- b \ 
PoK{b: A -A } 

V C[L}=e(A l ...A N ,x[L})- b J 

4.3 Hashing-Generator Construction 

Background The pairing-based scheme improves on 
the ElGamal scheme's communication overhead, at the 
cost of expensive pairing operations. In our hashing- 
generator scheme, instead of using a different secret to 
encrypt each plaintext element as in the ElGamal and 
pairing schemes, we reuse a secret but use a different 
generator for each encryption. 

This construction adds some complexity in the form of 
a setup phase, using Diffie-Hellman agreement to form a 
matrix of shared secrets, much like an XOR-based DC- 
net scheme would use to seed its symmetric-key PRNGs. 
For verifiability we cannot use conventional PRNGs in 
Verdict, but we can use Diffie-Hellman agreement to 
seed what may be viewed as a "verifiable PRNG," which 
we implement by raising a series of independent pseudo- 
randomly chosen generators to fixed, secret exponents. 

Construction During the protocol set-up phase, each 
client i establishes a Diffie-Hellman shared secret ry with 
every server j using their respective public keys g"' and 
g b j by computing r\j = H (g"' bj ) using a hash function H . 
Clients then publish commitments to these shared secrets 
Rij = g r 'i using a public generator g. 

The hashing generator construction requires a process 
by which participants compute a sequence of generators 
g[l], . . . ,g[L] of the group G, such that no participant 
knows the discrete logarithm of any of these generators 
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with respect to any other generator. In other words, no 
one knows an x such that g[i] x — g[j] for any i,j pair. 
In practice, participants compute this sequence of gen- 
erators by hashing a series of strings (the round nonce 
concatenated with "1", "2", "3", . . .), then encoding the 
hashed strings into group elements using methods dis- 
cussed in Section 15.31 This process assumes that ele- 
ments encoded this way are generators, which is not al- 
ways true but holds for the groups Verdict uses. 

Every client i then produces a series of shared secrets 
with each server j by computing: 

g[lp,...,g[Lp 

To use this hashing-generator scheme to create a ci- 
phertext, the client uses its shared secrets r,i , . . . , r,M with 
the servers, and the set of L generators to produce a ci- 
phertext (for / = 1,... ,L): 



m[l]g[lp 



■+riM 



As before, m[l] = 1 if the sender is not the slot owner. 
Although this construction might appear to require a new 
cryptographic assumption, its security follows from the 
m-DDH assumption 1 8 ], which itself follows from DDH. 

Server j's ciphertext is similar to the client ciphertext, 
but with the exponents inverted (for / = 1 , . . . ,L): 



rij r Nj 



Proof of Validity Prior to the round, members first ver- 
ify the commitments. Invalid commitments can trivially 
be proven false via the following knowledge proof: 

PoK{b:g"' b ' — A b ABj — g h } 

To verify client ciphertexts, the verifier first deter- 
mines the product of the clients' commitments: 

(R u )...(R l , M )=g r ->+- +r M 

A client then must prove that the exponent of this product 
is either equal to the exponent of its ciphertext or that the 
sender is the slot owner. (Note that the generators g[l] 
and g are distinct.) The client proof construction is then: 



PoK{r,y : 

C[l]=g[l] r A-AC]L]=g]L] r 
AR a ...R M =g r 

\/Y = g y} 

where Y is the slot author's public key. 
The server proof construction is then: 



PoK{r: 



C[l]=g[lYA---AC[L}=g[LY 



AR, 



Rnj - ; 



5 Implementation Considerations 

This section outlines a few of the challenges that an im- 
plementation of Verdict must address. 

5.1 Structuring Slots 

Each client within the DC-net has her own slot for trans- 
mitting anonymous messages. Much like the Dissent 
protocol l38l . each slot contains some metadata used for 
defining future slot state. A user can request a longer slot, 
potentially transmitting her message via a series of group 
elements, or even shut off her slot, using zero group ele- 
ments, to save bandwidth and computation costs. 

In Dissent, slots were reopened using a smaller single 
bit slot, however, that approach provided no verifiability 
and allowed a malicious participant to open all slots with- 
out repercussions. To provide verifiable slot re-opening, 
currently Verdict uses a naive approach of rotating a sin- 
gle transmission slot among closed slots with the owner 
of the shared slot independently and deterministically de- 
rived at the beginning of each round (e.g., the slot with 
index (round-index mod AO. The slot owner can either 
transmit a single message during this window or use it to 
open a long-lived slot for future use. 

5.2 Lazy Proof Verification 

If the servers always verify all client ciphertexts, verifi- 
cation is the protocol's dominant cost as Section|6]shows. 
To address this bottleneck, servers can lazily verify client 
ciphertext proofs only when a slot's output is invalid. To 
validate a slot's plaintext, the slot owner signs his plain- 
text using the anonymous signing key for the slot. 

Lazy verification introduces a risk that an attacker who 
owns / malicious clients can cause the servers additional 
verification work for / rounds. This work represents 
a much lower cost than blame in XOR-based Dissent, 
however, as Section [6] shows. Further, Verdict's servers 
can still complete attacked rounds after discarding bad 
ciphertexts, so the adversary can no longer halt commu- 
nication progress entirely for / rounds as in Dissent. 

5.3 Encoding Data in Group Elements 

The ciphertext constructions described in Section @] re- 
quire the slot owner to encode her message as a group 
element. We encode bitstrings {0, 1}' in elements of in- 
teger, elliptic curve, and pairing G2 groups as follows. 

Integer Groups As integer groups we use groups of 
quadratic residues modulo a prime p = 2q + 1 where q 
is also prime, for which the Decisional Diffie-Hellman 
(DDH) problem is believed to be hard. For these groups 
we adopt an elegant encoding method by Cramer and 
Shoup [14|: represent the bitstring as an integer r g 
{1, . . . ,q}, then encode it as r if r is a quadratic residue, 
and otherwise encode it as — r (mod p). 
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Elliptic Curve Groups We embed bitstrings as elliptic 
curve points via standard sampling methods. We first 
add k padding bits to the bitstring, interpret it as an x- 
coordinate, and compute a corresponding y coordinate if 



one exists with the equation y 



ax + b (mod p). 



If there is no corresponding y coordinate on the curve we 
increment the padding bits and retry. This process fails to 
find a valid point with probability at most (1/2) 2 [|30| . 

Pairing Group Recall that a symmetric bilinear map 
is a mapping e : G\ x G\ —> G2. In our usage, public 
keys are elements of G\ and plaintexts and ciphertexts 
are elements of G2. To implement the pairing scheme, 
we must therefore encode bitstrings as elements of G2. 

Instantiating with the Weil pairing, G\ is an elliptic 
curve group over ¥ p and G2 is the order-g group of roots 
of unity in the field F p 2 . The PBC library picks the prime 
modulus p so that —1 mod p is a quadratic non-residue. 
Elements in F_2 can then be represented in the form (a + 
and elements of G2 (roots of unity) satisfy the 
equation a 2 + j3 2 = 1 (mod p). This equation allows us 
to encode bitstrings in elements of G2 similarly to the 
elliptic curve case: add k padding bits, interpret the result 
as an integer a, and increment the padding bits until we 
find a /3 such that a 2 + /3 2 = 1 (mod p). The failure 
probability is again at most (1 /2) 2 . 

5.4 Maliciously Crafted Public Keys 

In Verdict, a malicious participant could calculate the in- 
verse of another member's public key and the cipher- 
text^) associated with it and transmit them as his own. 
This would cancel out the other clients' ciphertext, re- 
vealing that member as either the owner or non-owner 
of that slot. To prevent this class of attacks, all public 
keys must be transmitted with proof of knowledge of the 
matching private key. 



6 Evaluation 

In this section, we first explore Verdict's constructions 
and group selections using various microbenchmarks and 
then experiment using real-world applications using data 
traces from Twitter and browsing the Alexa Top 100. 

6.1 Implementation 

We implemented Verdict's protocol, Section [3~2l in C++ 
using the Qt framework. Source code is available at 
https : //github . com/henrycg/Dissent 

The cryptographic protocols, Section [4] were imple- 
mented using OpenSSL 1.0.1, Crypto++ 5.6.1, Botan 
1.10.0, and Stanford Pairing-Based Cryptography 0.5.12 
libraries for both integer and elliptic curve groups. Un- 
less otherwise noted, the evaluations use the group of 




3000 4000 
Plaintext message length (bytes) 

Figure 4: Ciphertext expansion factor (overhead) using 
the integer ElGamal, pairing, and integer hashing gener- 
ator protocol variants 

quadratic residues modulo a 2048-bit integer, the 256- 
bit NIST P-256 elliptic curve group 11271 . and a pair- 
ing group in which G\ is an elliptic curve over a 512- 
bit field (using PBC's "Type A" parameters) [24|. The 
microbenchmark results were gathered on Intel Xeon 
W3565 with a 3.2 GHz processor, and the macrobench- 
marks and end-to-end evaluations were gathered on the 
DeterLab 1161 testbed. 



6.2 Microbenchmarks 

Figure [3] illustrates the ciphertext generation throughput 
for each of the three protocol variants, three elliptic curve 
cryptography libraries, and three different group types. 

Protocol Variant Figure [3a] shows ciphertext genera- 
tion throughput for the three verifiable DC-nets schemes 
described in Section |4j ElGamal, Pairing, and Hash- 
ing. The fastest scheme, Hashing, can encrypt 20 KiB 
of client plaintext in a second, while the slowest scheme, 
Pairing, encrypts only around 3 KiB of plaintext per sec- 
ond. Unsurprisingly, the fastest verifiable scheme is still 
over an order of magnitude slower than the traditional 
(unverifiable) XOR-based scheme, which encrypts 600 
KiB of plaintext per second. As Figure [3d] shows, the 
cost of ciphertext verification is almost identical to the 
cost of ciphertext generation (message encryption). 

The three proof constructions also vary in the size of 
ciphertexts they generate (Figure 0). While the Pairing 
and Hashing schemes encrypt length L plaintexts as ci- 
phertexts of length L + 0(l), the ElGamal scheme en- 
crypts length L plaintexts as length 3L + 0(1) cipher- 
texts. As discussed in Section 14.11 for every plain- 
text message element encrypted, the ElGamal ciphertext 
must include an ephemeral public key and a proof-of- 
knowledge group element. Since the Hashing scheme is 
the fastest of the three and avoids the ElGamal scheme's 
ciphertext expansion, subsequent experiments use the 
Hashing scheme unless otherwise noted. 

Cryptographic Libraries For the schemes that sup- 
port integer groups, we tested implementations based on 
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(d) Ciphertext verification throughput for 
the three verifiable DC-net variants. 
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Figure 3: Throughput over plaintext message length. 



both OpenSSL and Crypto++, but found the performance 
nearly equivalent. We omit the graph due to space and 
henceforth use Crypto++ in integer group experiments. 

For elliptic curve groups, Figure[3blpresents ciphertext 
generation throughput rates when using the OpenSSL, 
Crypto++, and Botan libraries. The Pairing-Based 
Crypto library does not support computation over arbi- 
trary elliptic curves, so we could not compare PBC to 
the three general EC libraries. For larger messages, in 
which the point addition and point multiplication opera- 
tions dominate the computation, OpenSSL outperformed 
Botan by a factor of five and outperformed Crypto++ by 
40%. For the rest of the evaluation, the experiments thus 
use OpenSSL elliptic curves unless otherwise noted. 

Group Types and Sizes The choice of group (inte- 
ger versus elliptic curve) has a large impact on perfor- 
mance. As Figure [3c] illustrates, EC groups greatly out- 
perform traditional integer groups in ciphertext genera- 
tion throughput. Using the OpenSSL elliptic curve li- 
brary, a client can generate 25,000 KiB of ciphertext per 
second. In contrast, using the Crypto++ big integer li- 
brary, a client generates less than 1,500 KiB per second. 

Elliptic curves' performance advantage comes in part 
from the fact that, to achieve (roughly) the same level of 
security as a 2048 -bit integer group, an implementation 
need only use a 256-bit elliptic curve group ll28l . The 
arithmetic operations in elliptic curve groups are then 
much faster than similar operations in integer groups of 
equivalent security but of much larger size. 



Security Parameter Evaluating the ciphertext gener- 
ation throughput while varying the security parameter 
(group size) reveals that elliptic curves' performance ad- 
vantage over integer groups increases as the group sizes 
increases, as shown in Figure [5a] The peculiar through- 
put dip at 224 bits in the EC libraries is an artifact of the 
NIST elliptic curve parameters: this curve has a prime 
order equivalent to 1 mod 4, making modular square 
root computations less efficient than for the other NIST 
curves, which have prime order equivalent to 3 mod 4. 

Comparison with Traditional DC-net In small 
groups, Verdict's extensive use of public-key cryptogra- 
phy makes it substantially slower than traditional XOR- 
based schemes. Surprisingly, however, certain Verdict 
operations are actually faster than XOR-based DC-nets 
when the number of participating clients is large. As 
shown in Figure [6] in networks with more than 500 
clients, encrypting 1 KiB of plaintext with Verdict is 
faster than encrypting an equally long plaintext using a 
traditional XOR-based DC-net. 

In XOR-based schemes, every server must generate an 
L-bit pseudorandom string for each of the N participating 
clients, for 0(NL) computation per server. The algebraic 
properties of verifiable DC-nets, in contrast, allow the 
servers to "fold" the N clients' secrets together once be- 
fore computing their L-bit ciphertexts, yielding asymp- 
totically lower 0(N + L) cost. In networks of over 500 
nodes, the cost of performing the generating the pseu- 
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Figure 5: Throughput using the hashing-generator vari- 
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Figure 6: Comparison of server ciphertext generation 
time. 

dorandom strings in a traditional DC-net dominates the 
precomputation cost required in a Verdict DC-net. 

If servers always verify all clients' ciphertexts, then 
this 0(NL) verification cost ultimately dominates. If 
servers use lazy proof verification (Section |5.2t , how- 
ever, Verdict may be able to realize this asymptotic ad- 
vantage over traditional DC-nets in large networks. 

Accountability Cost A primary benefit of a verifiable 
DC-net construction is to reduce the cost of identifying 
misbehaving nodes. Figure [7] compares the cost of iden- 
tifying a misbehaving client in the XOR-based Dissent 
with the cost of identifying a misbehaving client in Ver- 
dict. Since the cost of verifying a client proof in Verdict 
is constant in the number of clients, the cost of account- 
ability is modest: a server verifies a client's ciphertext in 
less than one second. Further, the servers can success- 
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Figure 7: Time required to identify a misbehaving client. 

fully complete an attacked communication round after 
discarding any ciphertexts that fail to verify. 

Dissent, in contrast, requires a lengthy interactive 
"blame" process to identify which client has misbehaved. 
In a network of 1000 nodes, Dissent takes on the order of 
hours to identify a single misbehaving participant. Fur- 
ther, the disrupted communication round is unusable and 
must be restarted from scratch, allowing an adversary 
who controls / colluding members to block all commu- 
nication for / consecutive iterations of this costly blame 
process. In larger and more diverse networks, Verdict's 
verifiability thus ensures communication progress even 
if many clients may be adversarial. 

6.3 Anonymous Twitter 

Verdict's good performance on short messages and its 
ability to tolerate many dishonest nodes makes it po- 
tentially attractive for anonymous microblogging. In 
Twitter, messages have a maximum length of 140 bytes, 
which means that a single tweet can fit into a few 256- 
bit elliptic curve group elements. Twitter users can also 
tolerate latency of tens of seconds or even a few minutes 
(which would be unacceptably high to Web users) and 
in a group of Twitter users, generally a small fraction of 
users transmit at any one time. 

To test Verdict's suitability for such applications, we 
first scraped data from Twitter, then used it as input into 
a one-hour Verdict run. We repeated this experiment us- 
ing the three Verdict ciphertext constructions, as well as 
Dissent (an XOR-based DC-net scheme). We also ran 
the experiment using Neff's verifiable shuffle l26l . al- 
lowing comparison between Verdict and a state-of-the- 
art accountable mix-net. 

To construct the Twitter data set, we used a Python ap- 
plication to watch the public timeline, waiting for a post 
from a user with 1,000,000 followers. We then requested 
from Twitter 4,999 followers of that user and collected 
all Tweets from this set of 5,000 users for one hour as in- 
put to our test run. In the data set we obtained, we found 
672 active users with 3,320 Tweets. 

In the testbed topology, servers shared a common 100 
Mbps network with 10 ms latency, while clients shared 
a 100 Mbps uplink with 50 ms latency to their common 
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Figure 8: Rate at which various anonymity schemes pro- 
cess tweets, for varying numbers of active users. 
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Figure 9: Results of running a Twitter trace through var- 
ious anonymity protocols. "Baseline" indicates the time 
at which each tweet was recorded in the trace. 

server. Our first analysis, Figure [8] looks how the rate 
at which messages move through the anonymity system 
changes as the number of active participants increases. 
In both evaluations, participants were selected from the 
most active twitter users, thus only in the 1032 partici- 
pant evaluation were there any completely passive users. 
Our bandwidth analysis plots the total number of Tweets 
over the run time (60 minutes). Results below the base- 
line imply missing Tweets (i.e., tweets that took longer 
than one hour to propagate through the system). The 
important conclusions from this evaluation are that: (1) 
in almost all cases the DC-net variants run faster than 
the verifiable shuffle, validating our use of DC-nets; (2) 
our hashing approach can almost maintain pace with the 
original Twitter baseline, and (3) the pairing construc- 
tion outperforms the EIGamal construction, most likely 
because of bandwidth limitations. 
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Figure 10: Time required to download home page con- 
text for Alexa "Top 100" Web sites. 

We selected the set size of 264 participants for further 
investigation, since it was the largest number of active 
participants the Verdict protocol could keep pace with. 
Our results are found in Figure [9] The Verdict hash- 
ing scheme using elliptic curves is slower than Dissent 
(the XOR-based DC-net), but Verdict is able to keep up 
with the stream of tweets throughout the run of the trace. 
These results implies that Verdict might realistically sup- 
port pro-actively accountable anonymity for microblog- 
ging groups of up to hundreds of nodes. 



6.4 Anonymous Web Browsing 

Dissent demonstrated that DC-nets can be fast enough to 
support anonymous interactive Web browsing in local- 
area network deployments [38 1. Testing Verdict in a sim- 
ilar scenario, we find verifiable DC-nets to be slightly 
slower, but still fast enough for usability. Figure \W\ 
charts the time required to download home page context 
(HTML, CSS files, images, etc.) for the Alexa "Top 100" 
Web pages [2| on an testbed simulation of a WLAN net- 
work. On a network of 24 Mbps links with 20 ms node- 
to-node latency, and with 8 servers and 24 clients, Verdict 
still offers tolerable browsing latency. For example, the 
median Web page took less than one second to load with 
no anonymity, fewer than 10 seconds over Dissent, and 
just over 10 seconds using Verdict (Figure ITTb. 

Verdict and Dissent perform as well as they do in this 
scenario, in part, because only the upstream (request) 
traffic need be anonymized. The downstream (response) 
traffic from the Web server can simply be broadcast to all 
nodes over a non-anonymized broadcast channel. While 
Dissent is still faster than Verdict for anonymous Web 
browsing, in situations in which an adversary might con- 
trol a large fraction nodes (e.g., an Internet cafe), Ver- 
dict's much lower accountability cost could make Verdict 
usable where Dissent might be less so. 
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Figure 1 1 : CDF of time required to download home page 
context for Alexa "Top 100" Web sites. 

7 Discussion 

Beyond closing DoS attack vulnerabilities, verifiability 
could increase the flexibility and security of anonymous 
communication systems in other indirect ways, which we 
merely sketch here, though exploring them in detail is out 
of the scope of this paper. 

First, as Golle and Juels pointed out 1221 . verifiability 
could enable participants to construct their ciphertexts 
offline and submit them via arbitrary "dropoff" mech- 
anisms, such as delay-tolerant protocols ||20l or mailed 
USB sticks. While full support for offline participation 
would involve further technical and practical challenges 
out of this paper's scope, in general verifiability may be a 
prerequisite for offline DC-nets, since all the retroactive 
approaches to trace disruptors we are aware of rely on all 
or most participants (including the disruptor) remaining 
online and active in the protocol during tracing. 

Second, verifiability and delay-tolerant participation 
may lead to novel solutions to the challenge of long- 
term intersection attacks [23 1. Suppose for example Al- 
ice anonymously posts a series of messages over time 
that are all linkable to each other, though preferably 
not to Alice's real identity: e.g., a series of blog posts 
under the same pseudonym. If Alice posts these mes- 
sages anonymously in a large group or forum with many 
users, she might feel she has good identity protection. A 
much smaller number of users might be logged in at any 
one time, however, and an adversary powerful enough 
to monitor when users come online and go offline (e.g., 
an authoritarian government's state-controlled ISP) may 
correlate this information to Alice's linkable messages 
to reduce or eliminate her anonymity. If she posts three 
linkable blog entries at different times, for example, and 
of the three different subsets of users who were online 
at those times, Alice is the only user present in all three, 
then the adversary has de-anonymized Alice completely. 

One approach we are exploring to address long-term 
intersection attacks is by anonymity scavenging iTPSll . If 
different users come online at different times each day to 



post blog entries, for example, but a set of servers collect 
verifiable DC-nets ciphertexts throughout the day and 
only "open" the ciphertext submissions at the end of each 
day, then all users who contributed ciphertexts during 
that day forms one large anonymity set that the adversary 
is unable to separate via traffic analysis. Different users 
might participate at different rates to trade anonymity 
set size for responsiveness explicitly, and more sensi- 
tive users who post at higher-latency rates (e.g., once a 
day) could "scavenge" larger anonymity sets that include 
the many less-sensitive users communicating at lower 
latencies (e.g., once per second for chat or microblog- 
ging, or even sub-second for interactive communication). 
Some of these benefits may also be achievable in batch- 
ing mixes [15,18], but verifiable DC-nets offers a storage 
cost advantage: servers collecting verifiable ciphertexts 
can "fold" them together immediately upon verification, 
rather than having to collect and store large batches of 
messages to mix. These possible benefits are specula- 
tive and remain to be implemented and evaluated; we 
merely wish to point out that practical verifiable DC-nets 
may open up interesting new research directions beyond 
merely addressing DoS attack vulnerabilities. 

8 Conclusion 

The twin goals of anonymity and accountability have 
been at odds since the Chaum first proposed the DC- 
net. Building on prior work, we have presented three 
new practical and proactively verifiable DC-net construc- 
tions and we have implemented and evaluated them in 
the context of the Dissent anonymity system. Evalua- 
tion of Verdict shows that while Verdict's verifiability 
comes at some cost, the cost of proactive accountabil- 
ity may be far less than the cost of finding disruptors in 
existing anonymous communication systems. These re- 
sults suggest that disruption-resistant may be attainable 
in anonymous communication systems resistant to traffic 
analysis, even in large, relatively open groups. 
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